Contemporary marketing strategies employ a multitude of marketing levers to increase market share and consumption, attract potential customers and reward faithful patrons. Complex pricing structures and associated pricing strategies, in conjunction with product selection, cross selling and up selling methodologies are often used as marketing levers used for increasing and maintaining demand patterns. Prices are quoted to customers through quotes and orders, which serve as a set of starting prices and associated adjustments leading to the final net prices charged to the customer. The final price offered to the customer is based on list pricing, along with associated pricing adjustments stored as pricing rules, and presented to the customer on their quote. Therefore, the final quoted price for a product or a service is the result of one or more adjustments made to a set of base (starting) prices. The adjustments may be based on many considerations around the product, customer and quote context including, for example; customer purchase volumes—historical as well as current purchases, product availability, customer loyalty, market segmentation, location, or other factors like customer age.
Rules-based processing systems are employed to determine which rules apply to any situation and to enforce the impact of such rules by applying discounts on the starting list price. These systems are used for determining applicable pricing schemes and for determining and enforcing the impact of rules in other similar applications. Automated rules may be enforced by specifying one or more conditions (also referred to as the application context) under which each result is applied. In existing systems, this may consist of defining a set of application rules from scratch (hard coding) or, at best, defining such rules using a rules-entry interface. An implementation sequence (application logic) for the set of application rules must also be defined. In existing systems, the application logic is either hard coded or maintained as a mixture of data and logic that are not completely separated from each other. This makes the system relatively inflexible and makes it hard to quickly and rapidly roll out price changes.
For typical industries implementing applications of average complexity, the number of application rules may be quite large. The number of rules processed at any time is large because the current applications process all rules that exist in the application at any point in time. For example, pricing rules within the hospitality (hotel) industry may require the consideration of location, room type, day-of-week, customer-type, customer-age and contracted rate, among others, in making adjustments to a base price. Each of these pricing considerations may have numerous data points outlining pricing adjustments. For example, a global vendor may have hundreds or even thousands of rules that have to be processed before a price can be quoted. The inter-combination of the various rule and data point considerations could easily lead to a system having well over 10,000 pricing rules and data items.
The typical available solutions have drawbacks in a number of areas, including system implementation, use and maintenance.
To implement such an RBE requires the creation of numerous rules along with the associated rule logic and the implementation of both (rules as well as logic) within a processing system, which means manually entering a large amount of code (hopefully with the aid of a rules-based syntax). This requires a good deal of time and a high level of expertise.
To use such a system requires storing a tremendous amount of data in memory. That is, the entire RBE, including all of the application rules and the accompanying logic, has to be loaded upfront to obtain a result. For example, to obtain a price quote, all of the pricing rules and application logic have to be initially downloaded to the local data base or application from a database server. Data points (i.e. pricing rules and data logic) for a particular customer, product, or fulfillment context are then interpreted to determine an adjustment to a base price. The rules-based pricing engine (“RBPE”) then searches all pricing rules, regardless of whether they were relevant to the particular application context, and applies those rules relevant to the particular application context to determine a price adjustment. The price adjustment, if any, is applied to a base price to produce a price quote. This is time consuming and may lead to unacceptable response-time delays and scalability issues (e.g., a large number of users concurrently downloading a large amount of data).
Maintaining such a system also presents distinct difficulties that include the time, cost and level of expertise needed to make modifications to the application logic or application rules. A simple modification to a complex pricing structure may require changing the application code in many locations throughout an RBE. For example, this might include changing the way the application context for a particular rule is maintained and the way the the corresponding result is searched. Depending on how the pricing rules have been coded, this could require a high level of expertise and could take days, weeks, or even months to accomplish a set of modifications. This process takes time and costs a lot of money, having a monetary cost commensurate with such an undertaking. Since new marketing strategies and their accompanying price structures must be implemented quickly and rapidly in connected as well as disconnected mobile user environments to exploit market trends or produce a desired impact on revenue streams, such delays in implementing modifications can have costly repercussions, including loss of customers, lower demand and extended sales cycles.
All of the above-noted disadvantages of currently available systems may be exacerbated if the application rules storage and associated rule processing is not efficiently coded. For example, an RBE may include a particular application context that in all cases produces the same result. However, due to inefficient coding, the RBE may lack the logic to implement the rule efficiently, since not all rules need to fire repeatedly.